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Telecommunications network resource handling arrangement and 
method. 




The present invention relates to a resource handler for use in an 
operational support structure for managing a telecommunications 
network, comprising a service and resource database arrangement 
containing information regarding network resources- The invention 
also relates to a method of structuring information in a resource 
handler database arrangement for use in such an operational 
support structure. Also, the invention relates to a use of a 
resource handler for a service type handler in an operational 
support structure for a telecommunications network, for creating 
and maintaining service type recipes and their relations. 

ST-ATF: OF THTh AT1T 

Resource management in operation support systems for tele- 
communication is difficult due to the size and complexity of these 
types of networks. A telecommunication network normally changes 
constantly as new resources/services are added, and as old 
superfluous resources/services are removed or replaced. Often, a 
lack of information regarding available/redundant resources lead 
to stove-pipe solutions for particular services or networks with 
high levels of duplication. The lack of up-to-date information and 
the resulting duplication lead to higher management costs for the 
network operator. Sometimes resource investments are unnecessary 
because redundant resources may actually be available. There may 
be resources that supposedly are engaged by old services that are 
no longer active or have been replaced by new services that use 
other resources. 
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An operational support structure for a telecommunications network 
is for example described in US 5,640,505. This support structure 
is divided into a set of domains each of which provides a 
particular management function for the network. This document 
teaches a general support structure •■ but it provides very little 
details for implementing such a structure. Thus, there is no 
definite solution to the problem of how to handle network 
resources so that duplication is avoided. 

EP-A-0 820 203 shows a method and an arrangement for making use of 
resources in a telecommunications network. This arrangement /method 
is however not satisf actory\f or several reasons. It does e.g. not 
satisfactorily take into account the time "that e.g. a resource 
jjjL5 exists. To do that, would e\a. attributes have to be added 
containing information about time of existence; however, this 
would have to be done for everyVesource to make it meaningful 
which would considerably reduce theVerformance. 
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iJO Moreover it does not give a solution to the problem of adding 
Jl entirely new attributes. It is also a disadvantage that it cannot 
be used by arbitrary processes^bji4rT.T~~±-s. specif ically designed to 
support the object-oriented WH-p r0 cess s The solution in EP-A- 
0 820 203 is not sufficiently flexxbl-eT^ \ ^ 

25 

Ideally the service and resource database should be able to 
represent all existing and all future types of telecommunication 
equipment and network topologies in a simple data model in order 
to be able to manage the resources of an arbitrary network. 

<f^~-* SUMMARY O IV ' T Hh 1NVLN T 1UN 

One object of the present invention is to provide a flexible 
resource handler and method relating thereto which can be used by 
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arbitrary processes. Another object is to enable easy addition of 
new attributes (preferably dynamically) under operation, as well 
as new service types and new resources types. Particularly it is 
an object to enable modelling and handling of equipment with both 
transmissive and non-transmissive properties. 

According to a first aspect of this invention, there is provided a 
resource handler for use in an operational support structure for 
managing a telecommunications network, comprising a service and 
resource database arrangement containing information regarding 
network resources. The database arrangement is structured so that 
each resource in the network' has a time of existence as well as a 
place in a hierarchy of parent/child (s) relations. The resource is 
defined by the following data: 

a point identifier that has characteristics associated to 
it, in the form of an abstract description of its capabilities; 

an abstraction of the common network element in the sense of 
a group of points that are considered to belong together; and 

a connection which is defined by two connected points. 

Preferably, the point identifier also has characteristics 
associated to it, in the form of a list of label/value pairs. 

According to one advantageous embodiment of the invention, the 

element acts as a container for points, with the implicit 

characteristic that points on elements are possible to cross- 
connect . 

The database arrangement may be structured so as to model a 

topological view, i.e. how the resources are connected together. 
It may also be structured so as to model a time view, i.e. when 
the resources exist. 
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The database arrangement may be structured so as to model a 
hierarchic view, i.e. how the resources are related in 
parent/child relationships. It may also be. structured so as to 
model a characteristic view, i.e. by means of a list of 
characteristics of each resource. Also, the database is structured 
so as to model a usage view, i.e. which resources are combined to 
form a complete service instance and the time when that service 
instance exists. 



Preferably, the topological view, the time view, the hierarchic 
view, the characteristic view and the usage view are integrated in 
p a da ta model for enabling control of each resource and the use of 

it in service instances. 



J^j 15 Preferably the database arrangement comprises a first, separate, 
p; database and a second, separate, database. One of the databases is 

used for resource types and resource instances whereas the other 
H 1 is used for service types and service instances. 

C3 

yfj20 According to a second aspect of this invention, there is provided 
It a method °f structuring information in a resource handler database 

arrangement for use in an operational support structure for 
managing a telecommunications network, comprising the steps of 
allocating each resource in the network a time of existence as 
25 well as a place in a hierarchy of parent /child (s) relations, and 
defining each resource by the following data: 

a point identifier that has characteristics associated to 
it, in the form of an abstract description of its capabilities; 

an abstraction of the common network element in the sense of 
30 a group of points that are considered to belong together; and 
a connection which is defined by two connected points. 
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According to a third aspect of this invention, there is provided a 
use of a resource handler for a service type handler in an 
operational support structure for a telecommunications network, 
for creating and maintaining service type recipes and their 
relations. 

Preferably, the service type recipes provides a framework for 
service types, operations on service types, parameters on service 
types, hierarchical relations between service types, hierarchical 
parameter relationship, and translation of service types and 
associated parameters values into resource requirements and 
service type requirements. 

The service type handler may be used for selecting between 
different types of required services, different types of required 
resources and different service instances. 

Advantageously, the selected resources requirements are 
transferred to a resource handler that does the actual resource 
allocation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will in the following be further described in a non- 
limiting way with reference to the accompanying drawings in which: 

schematically illustrates the relationship between the 
concepts of product (service) instance/type and 
resource instance /type, 

schematically illustrates the relationship between 
elements, points and connections, 



FIG. 1 



FIG. 2 
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FIG. 3 shows the system environment of the service and 
resource database arrangement of the service 
configuration, 

FIG. 4 is a block diagram which illustrates the relational 
structure of a service and resource database 
arrangement, and 

FIG. 5 illustrates the table relations and product type 
definitions. 

-DE3Efti fcBP--DESCRj ^T TriM nr TTir TTTWITTTON 

As there are many aspects of a telecommunications system, a 
structure of the information has to be made into parts for 
interaction between product /service types and product /service 
instances. For example, it is possible to have one part of the 
system handling product/service types and their translation to 
product/service instances and/or references to resources, a second 
part for binding information about product/service types and 
product /service type pricing, a third part for the product /service 
instances and a fourth part for keeping track of all procedural 
code for data manipulation. 

This basic modeling idea is illustrated in FIG. 1, and it 
comprises four basic areas (domains), the product/service type, 
the product /service instance, the resource type and the resource 
instance. The type areas are to be seen as where the drawings and 
design specifications are placed and the instance areas are where 
the raw material and the ready products /service are located. Thus, 
it is very important to make a clear distinction between the type 
of a product/service and the instance of a product /service as well 
as between a resource type and a resource instance. 

Each product/service type is defined by name, parameters, revision 
level and behavior. Thus the product /service type can be viewed as 
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a parameterized template for a product/service instance. Each 
product/service type has one or more revisions. As a 
product /service type may consist of other product /service types, 
some product /service types are placed in a hierarchy of 
parent/child relations. It is of utmost importance that a 
product/service type has no knowledge of the product types it is 
part of. It. may know things, about the product /service types it 
consists of. One parent product/service type may have the 
possibility to fork to one or several child product types. 

A product/service instance is the realization of a product/service 
with all parameter values set to their final values. Since the 
product/service types have a hierarchy, the product /service 
instances also must have a hierarchy. The product /service process 
is the procedure referenced to by the product/service type. It 
contains the precise and complete instructions how to manipulate a 
product/service instance. 

The concept of resources iNs used in order to have a concept for 
all "real" things in the\ system. It is very important to 
distinguish between two tthings, resource creation, i.e. 
installation of a new telephone line, and resource allocation, 
e.g. changing the state of an existing telephone line from unused 
to used. 

The resource type is the identity of an abstract description of 
the resource needed to implement a product .type. Product/service 
types having children may have references to resource types. 
Product /service types having no children must have references to 
resource types . 



The resource instance is the actual instantiation of a resource 
type. Product/service instances having children may have 
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references to resource instances. Product/service instances having 
no children must have references to resource instances. 

The relationship between elements, points and connections is 
illustrated in Fig. 2 which is an abstract graphic view of a 
telecommunication network. Each of the squares in Fig. 2 
represents an element 10, the dots are points 11 and the fat lines 
are connections 12. The thin lines in the lower left element are 
also connections, only scaled down in width to fit the element. 
This is represented in the Resource Type and Instance Data Base 
(SRDB) according to this invention, in the form of tables in a 
relational database. 



Having an SRDB is to have a formal and abstract model for 
describing a telecommunication network, its parts, their 
capabilities, how the parts are connected, by whom and when a part 
is used and so on. What exists in SRDB are lists of elements, the 
points on these elements, the capabilities/attributes of each 
point and how the points are connected. These lists (in the form 
of database tables) are filled with information of what equipment 
exists (and when it exists), what it can do and if it is used by 
someone . 

The point 11 is known under many names, such as port, termination 
point, external access point, binding post etc. in the real world. 
In SRDB they are abstracted to one concept, the point which in 
essence is an identifier. To distinguish between different types 
of points, every point must have a type that is a formal abstract 
description of its capabilities. A point type may have one or 
several capabilities. A point must always belong to an element, it 
can not exist on its own. 
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The element 10 is in essence a group of points that are considered 
to belong together. To be. an element , the points that are attached 
to it must have full connectivity to each other, i.e. any point 
must be possible to cross-connect to any other point within the 
same element. This connectivity may be restrained a bit as the 
capability/attribute types of the points may have the requirement 
that the same capability/attribute must exist on both points in 
order to be able to cross-connect. 

The connection is the very information that says that a point is 
connected to another point. In reality this is a pair of points. 
There are basically two kinds of connections, the infrastructure 
connection, i.e. a wire, and a cross-connect, which is 
controllable . 

The capability is a collection of attributes. Each attribute is in 
essence a pair consisting of the name of a parameter and the value 
of the parameter. This is the formal way to describe the 
characteristics of a point type. 

The service instance is the entity that in itself has all the 
common data regarding the resources used by it and it has 
references to these resources. 

Particularly attributes are only connected to points and relations 
are used to connect points to elements and to connect points to 
connections. There may however be a few fixed attributes also on 
elements and connections. They are selected very carefully since 
they should always be there such as time of existence, name of the 
resource etc. The main point is that there is no possibility 
whatsoever to connect optional or any attributes, attribute, to 
elements or connections. Instead all the characteristic features 
are in the points where it is possible to provide a connection to 
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an arbitrary number of attributes. The elements actually merely 
function as "place-holders" to which the points can be connected. 
The functioning of connections is similar i.e. their functioning 
is to indicate that two points are connected. 



Still further, in the database arrangement of the present 
invention, every resource (element, point, connection) preferably 
has a time of existence, which strongly underlines the 
consciousness about the meaning of time. 

In a particular implementation the database arrangement comprises 
fields enabling the use \of a regular code (e.g. C, Java™) if 
needed, which gives a high flexibility. According to the invention 
does not every resource necessarily have an (explicit) connection. 

In a most advantageous implementation of the invention it is 
possible to distinguish between different types of attributes, 
meaning, first, that the objects are "typed", and, second, that it 
can be distinguished between said types. It is preferable at least 
distinguished between attributes of type "transmissive" and of 
type "non-transmissive". One example on a resource with non- 
transmissive attributes is an e-mail account. It has a memory but 
no transmissive attributes like e.g. bandwidth. Through "typing" 
the attributes it gets easy to model and manage equipment having 
both transmissive and non-transmissive properties, i.e. equipment 
etc. which in principle fall outside the common scope of the 
telecommunication network, like servers. 

The concept of hierarchy is used in many places in SRDB in the 
form that elements 10, points 11 and connections 12 may have 
children, i.e. they may have an internal structure. This is 
described in the form of a parent/child relationship in a table. 
Preferably, according to the invention the model is clearly 
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hierarchical with parent/child relations both in elements, points 
and connections. 

Fig. 3 shows the system environment where the Service 
Configuration (SC) mainly consist of the activation engine 13, the 
Service Request Processor (SRP) 14 for upstream system 
communication, the Network Element Processor (NEP) 15 for 
downstream system communication, Resources Type and Instance 
Database (SRDB) 16 for information about the network resources, 
and Service Type and Instance Database (STDB) 17, see FIG. 5, for 
the service type and instance hierarchy. Internally, the 
activation engine 13 consist of Service Activation Request Manager 
(SARM) 18 a part of an Automatic Service Activation Program (ASAP) 
and the Service and Resource Instance Manager (SRIM) 19. 

In a particularly advantageous implementation of this invention 
the database arrangement is separated into two databases, (SRDB 
and STDB) , one of which, SRDB, contains the resource types and 
resource instances, the other, STDB, of which contains the service 
types and the service instances. 

The connection between STDB and SRDB is such that for external 
uses of the database arrangement, messages about which attributes 
are wanted, are sent from the service type and instance part 
(STDB) (down) to the resource type and instance part (SRDB) . It is 
thus a very loose coupling. The intention of using such a loose 
coupling or connection is that sometimes the complexity involved 
with the service types is not wanted. Instead "raw" or "pure" 
resource types/instances can be obtained directly from the 
resource part. (SRDB) of the database arrangement. 
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Through separating the database arrangement as referred to above 
it is possible to define service types using resource types (with 
new attributes) which still not are defined in the resource part. 

The STDB 17, see FIG • 5, contains all information on how to 
translate a specific service type to resources, to enable creation 
of new service instances. The SRDB 16 is the information source 
and depository of SC. 

A simplified view of tfle flow of information is that a Common 
Service Description Layer \x:SDL) command is sent by the SRP 14 to 
SARM 18 where it is translated to an Atomic Service Description 
Layer ASDL command and routeckto SRIM 19. SRIM then asks STDB 17 
and SRDB for additional information which is used to make a new 
CSDL command is translated to a\ ASDL command and routed to the 
NEP 15. The response from the NEPv follows in principle the same 
way backwards, where return status aHrf data is used to update SRDB 
16. 

The creation of a DuoCom instance is now used as an example of how 
to use the information in the data structures. The product DuoCom 
is assumed to consist of the sub products ISDN Access, E-mail, 
Personal Home Page and 020-connection. These five products, 
together with all relevant parameters, parameter values, resource 
definitions, location of resources, product information, product 
type cost, revision levels etc. and the associated provisioning 
control are considered to be entered in the product type data 
structure. 

Step zero is that an initiator, probably a customer care system 
(at some convenient time) has got access to an Operator Product 
Portfolio (OPP) and knows at least the names of the available 
products. When an end user contacts the customer care system, the 
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customer is given a list of product/service types to select fro 
In this case the DuoCom product is the interesting one, so 
request is made for more information about the product/servi 
type. 




In step 1 the OPP, by using the product name and the fact that 
product information is wanted as parameters, looks in the 
product /service type information table where all aspects of 
information and where to find it is located. 

In step 2, assuming thfat the customer wants the product, in the 
following is referred tio a product, it should however be clear 
that this also covers a \service, a feasibility check is made to 
check if it is possible to\ implement the product with the existing 
conditions, i.e. if all prerequisites are fulfilled. Now a "call" 
for this code is made. As th\e execution starts, this code uses the 
product type is input to loo\k in the Product type hierarchy. By 
looking here it is possible tio find out which (sub) products the 
DuoCom product is composed of. \n this case the four product types 
ISDN Access, E-mail, Personal HoVepage and 020-connection will be 
found. As they in turn may consist of further more simple 
products, the Product type hierarcfW is once again examined to see 
if the new products have sub products and so on until no more 
product types are found. 

s some of the (sub) products may be optional, i.e. the end 
ustomer has to be asked the (sub) product is desired and informed 
about the possible choices. \his results in an interactive loop in 
which the customer picks thte desired (sub) products. As these 
^sub) products are selected, theV Product type operation parameters 
and the Product type parameter Vables are examined to find out 
which parameters are needed. As th\s selection of (sub) products is 
dynamic to its nature, the Product type relations table is 
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examined to check that combinations of incompatible product types 
are not accidentally ^created. When this loop has ended, the 
Product type prerequisites and the Product type resource 
prerequisites tables are ex^riined with regard to Product instance 
data and resource data, if tnk sufficient amount of resources or 
existing product instances are available, so' that it is possible 
to instantiate this new product instance. ' 

In step 3 the Product type cost and Product type hierarchy tables 
are examined to get the cost for all individual (sub) products . It 
is however left to the customer care system to interpret and 
customize this information for the customer. This price system- may 
be in an internal currency and the customer care system may 
transform this currency into a local currency. 

In step 4, assuming that the feasibility showed that 
implementation was possible , the created instance order may be 
issued, i.e. to take all data from the feasibility and create one 
or several product instantiation orders. This will insert one or 
more product orders in Product order tables and result in a tree 
of product instances in the Product instances tables. 

In step 5, when the time of delivery arrives, it is finally up to 
the provisioning processor to activate the product,, i.e. 
traversing the product instances in the product instance hierarchy 
and to read out all data and give orders to the underlying 
resource managers to activate the reserved resources. 



All data is stored in \ relational database(s), see FIG. 4 which 
shows only the table names and the fields in each table that has 
^ relations to/from them. The Ntables may be created by reading from 
standard text files with SQL commands. 



